1. Technical Field
The invention relates to service management and service presentation systems wherein measurement data regarding services delivered by Service Providers to customers are gathered and handled to compute and communicate service indicators defined in Service Level agreements and, in particular, relates to qualifying means in a system managing the Service Levels provided by Service Providers.
2. Related Art
A Service Provider (SP) provides or manages resources for its customers. A resource can be a server, a particular application on a server, a networking device, people in a help desk to answer users, people to fix problems, people to manage and change systems configuration and location, . . . etc . . . or a complex solution made of multiple elements to accomplish or support a customer business process. The Service Provider and the customer can be different firms, or different departments in a large global enterprise where departments are organized as support services for other departments, e.g. Marketing, Research, Sales, Production,
Normally, a Service Level Agreement (SLA) is signed between a provider and a customer to define the role of each party and to remove any ambiguity from the business relationship.
Such a SLA:                Identifies the parties involved in the agreement.        Describes the service to be provided, and identifies in a measurable and quantifiable manner indicators of the quality of the service on which obligations will be set, with a possible series of exceptions and stipulations in the way to calculate these indicators.        Defines the obligations, called Service Levels (SL), to be met on the identified indicators, so that the expected quality of the delivered services is set in an un-ambiguous manner.        Defines the agreement period for which these obligations are set forward.        Pre-defines penalties to be paid/executed by the SP if the commitment(s) is(are) not met. If a commitment is exceeded, a reward can also be predefined, to be paid by the customer.        Also defines reporting policies, corrective actions, dispute resolution procedures, termination criteria, intellectual property.        
A SLA is encountered when considering utilities to be trusted “always-on” services such as providing water, electricity, gas, telephone, e-service (e.g., e-Business On Demand), etc. In fact, a SLA exists when a specific service offer including commitments is engaged with a customer.
By itself, a SLA does not bring any change in the level of service delivered. The Service Provider and/or the customer need to implement a Service Level Management (SLM) program that will actually result in higher levels of services. Indeed, a SLA only specifies the agreed criteria for determining whether or not a set of agreed service quality levels are met. When not met, the issue is to determine what caused the violation, maybe how to improve the service, or change the SLA or the provider. The Service Level Management begins with the development of new service levels for a new contract and continues throughout the life of the contract to ensure Service Level commitments are met and maintained.
The Service Level Management is commonly identified as the activities of:                negotiating, identifying and agreeing the measurable services that support the Business Process of a customer, and defining the SLA articulation in an offering for service with Service Level Objectives (SLO) also known as Service Level Targets (SLT),        monitoring resources used to deliver a service and capturing data on how well these resources perform from monitors or from logs,        calculating intermediate and high level Service Levels results or scores using the predefined service parameters formulae (called metrics) and taking into account all kinds of exceptions that can occur, assessing attainment versus commitments and possible penalties or rewards,        assessing impact of operational outages or degradations in terms of SLAs (services) and financial impacts, alerting in real-time of possible or effected outages, diagnosing problems for resolution, enforcing corrective actions wherever possible to regulate the delivery system and therefore try to proactively guarantee the achievement of obligations,        reporting to the provider and the customer on real numbers versus contractual numbers, and sealing final numbers to be used for rebates or rewards,        rebating to customers when commitments are not achieved, or rewarding the provider when commitments are exceeded, and        refining, improving and reviewing SLA definitions, Service Levels and services that support the customer's Business Process.        
Today, there are SLA Management Systems which are automated for managing SLAs such as IBM Tivoli Service Level Advisor, Computer Associates SLM, Digital Fuel or InfoVista. They are built to accomplish, at least, a minimum set of tasks such as capturing data from monitoring systems, and they participate or supply information to other service management activities such as alerting, enforcing or reporting.
However, for proper Service Level Management and in particular for continuous and deterministic service improvement, or for refining and renegotiating SLA contract terms, producing Service Level results data from measurement data alone is not sufficient. First, not only the committed top service level results need to be produced, but also intermediate SL results representing service components meaningful to the Service Provider and used in this top high level result, or Service Level related summary and detailed data. Secondly, it is necessary to show how base measurement data related to technical elements in the service delivered contribute to the SL result so that it is possible to trace back what needs to be modified to improve the SL result and it is possible to quantitatively track the detailed real effect of improvement actions on the technical elements of the solution. These data can then be used by people or by other enterprise management automated solutions (auto-correcting systems, reporting systems, data mining systems, etc.) to pinpoint areas for improvement and to track results of actions.
Few common elements can be identified in Service Levels for devising a common qualification policy to be applied on measurement data for this purpose, as there can be significant variations between two Service Levels, and as it depends on each Service Level business logic which can in turn be specific to each customer. This needs to be adapted to each case. To further increase the complexity of the case, even two similar or analogous Service Levels can require significantly different processes to produce close but different intermediate Service Level or summary data, or even data in slightly different forms (like a percentage which can be a number between 0 and 100, or a decimal number between 0 and 1). Such cases exist because the surrounding systems using the data produced by the SL Management solution can change for each customer, or because the customer requires to see different intermediate and lower level results contributing to the end service level, or because the operational teams delivering the services are not the same and have different processes requiring different data.
None of the above mentioned solutions addresses the problem in a satisfying manner. They need to constantly redevelop a dedicated process specific to each SL business logic and each environment. Therefore these solutions spend development resources and maintenance activities on the SL Management solution provider side, are costly, and become a bottleneck for the use and deployment of the SL Management solution. In some cases, these processes are done as part of data extraction mechanisms from database to database, and lack flexibility and need specialized skills.